\chapter{Language Workbenches}


\section{Existing Language Workbenches}
In our attempt to frame our project, an obvious and essential step was to study the state of the art in term of language workbenches.
Among those studied were Meta-Programming System, MetaEdit +...
%TODO add the others

In this section, we introduce those editors and we try to compare them in order to have an idea on which criteria are to be taken into consideration to characterize workbenches in the most relevant way.

%%begin introduction to logo and to the work made with it
In order to get familiar and to compare all those workbenches together, we modeled in each of them a part of the Logo DSL \cite{LOGO}.
The DSL contains the different concepts:
\begin{itemize}
\item A \textbf{canvas} is the root concept and can be seen as a container. The DSL actually define several command in order to write on the canvas.
\item A pen can be \textbf{down} or \textbf{up} in the sense that it is in contact or not with the canvas
\item The pen can be moved \textbf{forward}, and we are able to rotate it to the \textbf{left} or to the \textbf{right} in order to change its direction.
\item each instruction can be \textbf{repeated} for a given number of iteration.
\end{itemize}
To give a semantic to this language, we will follow an operational approach, meaning that the way the DSL is interpreted by the workbench will define its semantic.
(in other words we'll have a look at the code generated from the DSL and especially at its execution).
This DSL was preferred amongst others for several reasons.
First of all it is small enough in order to be modeled in a limited time. Then concepts are of different kind; while some have only behaviors like the forward concept, some others are more of a data container type like the pen concept, and we also can play with control structure with the repeat concept.
%%end of introduction to logo and to the work made with it



\subsection{Meta-Programming System}

\begin{figure}[h]
	\caption{\label{Figure 1a} MPS Overview}
   \includegraphics[scale=0.4]{images/MPS}
\end{figure}

Meta-Programming System (MPS) is a language workbench proposed by Jetbrains and based on IntelliJ IDE. It allows you to define the syntax of your own DSL (\ref{Background}) really precisely through the definition of what they call aspects.

There are 5 different aspects you can define.
\begin{itemize}
\item \underline{The structure aspect}, describes the abstract syntax of your DSL, it allows you to introduce new concepts for your language and to link those together when needed. 

\item \underline{the editor aspect} let you define the concrete syntax of your DSL, in other words, it allows you to state precisely how something written in your language should look like.

\item \underline{the type system} aspect is in some extends closer to the semantic notion as it allows to give some "type specific" properties (comparison rules, etc...) to concepts defined in the structure aspect.

\item \underline{the behavior aspect} allows to modify the behavior of certain concepts. Indeed, each concepts are implemented by a class (we are not yet speaking of code generation) that proposes several methods.
Those methods define the behavior of the concept. One is used to define the scope in which an instance of the concept has to be accessible for example.

\item \underline{the constraint aspect} allows you to define constraints over all your concepts .

\end{itemize}

All of those aspects are editable in a structural editor.
One of the main advantages of this kind of editor is that it allows you to work directly with the syntax tree of your language, and to dispose of auto-completion and "syntax-verification" everywhere.
Another benefit of working directly with syntax tree rather than on an intermediate text base representation, is in the case of extension of the language. In the simple scenario where we want to merge to language that use the same keyword with different semantics, we can't possibly relate one occurrence of the keyword to its original semantic if we work on the text base representation. This problem is avoided while using syntax trees thanks to the different hierarchies in the syntax of the two languages.

Now that the DSL has its syntax well defined, it is possible to create a code generator that will have to be tuned in order to link each keywords to the java code they shall have an impact to.
That's the way the semantic is given to the DSL.
Once each concepts has been mapped to given pieces of code, the generator is ready to generate java code for any instance of the DSL.

Figure 1a is an attempt to relate each of those aspects and what they impact together.


\subsection{MetaEdit +}


\begin{figure}[h]
	\caption{\label{Figure 1b} MetaEdit+ Overview}
   \includegraphics[scale=0.4]{images/MetaEdit+}
\end{figure}

MetaEdit+ is a commercial tool proposed by MetaCase.
Following 4 basic steps that we will introduce later, this workbench helps you create your own DSM (Domain Specific Model), and this in a completely graphical fashion. Instances of the DSM can then directly be used to generate a working application.

The 4 steps followed to create a DSM in MetaEdit+ are the following :
\begin{itemize}
\item \underline{The definition of concepts} is the first steps that has to be taken in order to create a DSM. The domain concepts are expressed in term of objects, relationship, roles, port, and individual properties. 

\item \underline{Rules} are expressed in order to enforce model properties. They are meant to define the correctness of models, and to define constraints over the concepts.

\item \underline{Symbols} define the concrete syntax of our DSM. They are only meant to give to each concepts the graphical representation desired. You can make the representation of a symbol dependent of concept's properties and other various information, thus enforcing behavior to the symbol, and making the whole model dynamic.

\item \underline{Generators} can be seen as bridge from DSM to various output formats, from XML to java code.
One can create its own generator, but numerous are already available as templates.


\end{itemize}

Figure 1b is an attempt to provide an overview of MetaEdit+, by relating each of those previously enumerated steps to what they might impact. 

In my opinion, one of the really strong point of MetaEdit+ is that  the tool provides a graphical view for everything that can be edited, or set by the user.
It is thus easier to see relations between concepts and to have an overview about what is modeled.
The semantic for each symbol is given from \_\_\_\_\_\_ . The problem about model composition that was solved by the use of syntax trees in the case of MPS is thus not a problem in MetaEdit+ as each symbol has its semantic defined independently of its representation. 


\subsection{ATOM3}

To be done

\subsection{Comparison}
In one of her book dealing with software language engineering (\cite{Kleppe2008} section 1.2), Kleppe introduces a comparison between modeling language and programming language.
As the workbenches taken into consideration have different approaches to the problem of providing a workbench for language creation and edition, we might consider and as after all it's all about languages at the end of the day, we might consider the criteria she's using in her comparison.

\begin{tabular}{c|c}
\caption{Comparison table as it is given in \cite{Kleppe2008}}
\textbf{Modeling Language} & \textbf{Programming Language}\\
Imprecise & Precise \\
Not executable & Executable \\
Overview & Detailed view \\
High level & Low level \\
Visual & Textual \\
Informal semantics & Execution semantics \\
By-product & Core product \\
\end{tabular} 

 
\subsubsection{Graphical vs Textual}
As you can see by comparing Figure 1a and Figure 1b, the two workbenches are fundamentally the same.
One of the main difference, which is not neglectable though, is that while MetaEdit+ is working essentially with graphical models, MPS is rather focusing on providing all the support needed to efficiently define a text-based DSL.
What we mean by efficiently is that the workbench let few rooms to errors, and typos thanks to the exclusive use of syntactic trees in all the editors it provides.
One of the limitation of MPS is the lack of graphical representation. This limitation is not shared with MetaEdit+ as this workbench is, as we previously mentioned, mostly working with graphical representation of models. Those representation allow the user to have a clear idea of what is modeled, but it is not trivial to define a "textual" syntax from it.

A comparison criteria that can come to our mind might thus be whether the tool is focusing on providing support  for a textual DSL, or if it is focusing on "graphical views edition". We might also might want to distinguish in the case the workbench provides mainly textual editing views, if it also provide a way to graphically represent the DSL. (as this is one of the functionalities we plan to achieve using alloy as a base for our workbench)

 
\subsubsection{Semantic}

In MPS, the semantic of keywords in the DSL is given through the mapping to (Java) code snipplet.

MetaEdit+ the semantic of symbols is defined by \_\_\_ 
TODO : investigate the watch example to learn more about that.

